Conversation
dbee0ef to
9e77198
Compare
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
| // Note: the only thread that should need to be attached is Envoy's engine std::thread. | ||
| // TODO: harden this piece of code to make sure that we are only needing to attach Envoy | ||
| // engine's std::thread, and that we detach it successfully. | ||
| static_jvm->AttachCurrentThread(&env, NULL); |
There was a problem hiding this comment.
I am going to add thread detachment in a subsequent PR, as it requires introducing engine level callbacks. I don't want to make this PR any bigger.
library/common/engine.cc
Outdated
| event_dispatcher_ = &main_common_->server()->dispatcher(); | ||
| cv_.notifyOne(); | ||
| } catch (const Envoy::NoServingException& e) { | ||
| return ENVOY_SUCCESS; |
There was a problem hiding this comment.
What makes NoServingException a successful run?
|
@mattklein123 I am assigning you in case you can take a look, given mike (initially) and I (later) were the ones that wrote the code. |
|
@junr03 just posting to say I think the updates you've made look good. 👍 |
|
Can we mention that this resolves #492 in the PR description and close out that issue when this merges? 😃 |
I wanted to to that in #507 as that completes the work for the crash 100%. It also completes work for #445. @rebello95 Does that sound good? |
|
Sure, SGTM |
|
Hm. I do think I'd suggest that this PR more directly addresses #492, and is probably the most relevant if we're ever looking for that commit. |
|
Sure, I can add it here. |
mattklein123
left a comment
There was a problem hiding this comment.
Nice, LGTM at a high level.
| // Note: the only thread that should need to be attached is Envoy's engine std::thread. | ||
| // TODO: harden this piece of code to make sure that we are only needing to attach Envoy | ||
| // engine's std::thread, and that we detach it successfully. | ||
| static_jvm->AttachCurrentThread(&env, NULL); |
There was a problem hiding this comment.
will do in subsequent PR to avoid re-approval and re-running CI
There was a problem hiding this comment.
Description: this is a follow up to #498. This PR introduces `envoy_engine_callbacks`. They are similar in nature to envoy_http_callbacks. The difference being that they are not exposed all the way to consumer level in the library as it is not needed right now. However, one can see how by adding a type erased context pointer, and following the platform patterns for http callbacks we could thread this all the way up if need be. The immediate need for these callbacks is to detach the engine's native thread from the JVM on Android. Risk Level: med -- adds complexity to engine management. Testing: local testing on devices (Lyft and example app on iOS and Android). In conjunction with #498 this PR Fixes #492 #445 Signed-off-by: Jose Nino <jnino@lyft.com>
Description: #498 did not fully solve #492. The reset cleanly destructed all objects. However, because destruction was posted in to the event dispatcher, the event dispatcher was left with bad accesses. This PR fixes the issue by issuing shutdown on the dispatcher, and only destructing once the event loop has exited and control has returned to the Engine's run function. Risk Level: med - fixing crash on shutdown Testing: local Fixes #492 Signed-off-by: Jose Nino <jnino@lyft.com>
Recent changes (namely #498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling `send` on engines that hadn't finished starting on these threads. This PR removes the custom threading logic in Swift in favor of simply using the new threading being done within the core. Another PR will make the same change on Android. Signed-off-by: Michael Rebello <me@michaelrebello.com>
Recent changes (namely #498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling `send` on engines that hadn't finished starting on these threads. This PR removes the custom threading logic in Swift in favor of simply using the new threading being done within the core. Another PR will make the same change on Android: #531. Signed-off-by: Michael Rebello <me@michaelrebello.com>
Description: "Recent changes (namely #498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling send on engines that hadn't finished starting on these threads." This PR removes the custom threading logic in Kotlin in favor of simply using the new threading being done within the core. Parallel to #530. Risk Level: med - reduce threading complexity Testing: local app. Signed-off-by: Jose Nino <jnino@lyft.com>
Recent changes (namely envoyproxy/envoy-mobile#498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling `send` on engines that hadn't finished starting on these threads. This PR removes the custom threading logic in Swift in favor of simply using the new threading being done within the core. Another PR will make the same change on Android: envoyproxy/envoy-mobile#531. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Recent changes (namely envoyproxy/envoy-mobile#498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling `send` on engines that hadn't finished starting on these threads. This PR removes the custom threading logic in Swift in favor of simply using the new threading being done within the core. Another PR will make the same change on Android: envoyproxy/envoy-mobile#531. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Description: create a class to manage Envoy lifecycle and allow for graceful teardown. Teardown is now graceful for both iOS and Android. Envoy's codebase expects to have shutdown happen from the main thread. However, in mobile the thread the engine runs in is not the main thread of the process, and thus shutdown/destructors were not getting run from the thread the engine was started on. This PR makes sure that the engine is destructed/shutdown from the thread that it ran in.
Risk Level: high. This PR changes state management for the engine, and initializes it on a std::thread instead of a platform thread. iOS thread management is afaict handled gracefully. On Android the native thread has to be attached and detached from the JVM. This PR attaches the native thread, but the work to detach is a bit involved so will come in a subsequent PR.
Testing: local device testing.
Fixes #492
Co-authored-by: Jose Nino jnino@lyft.com
Signed-off-by: Mike Schore mike.schore@gmail.com